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INTRODUCTION 

Instrument and sensor networks are one of the most impor- 
tant elements of process and automation industries. Although 
intelligent instruments and sensors are applied extensively, 
in some cases, there is still no intelligence associated (par- 
ticularly with the sensors) as they behave as mere sensing 
elements. However, there has always been a need to monitor 
the processes with the classical elements of network manage- 
ment, such as faults, configuration, performance, accounting, 
and security. At this moment in time, most of the sensor net- 
works in processes lack a standardized method of handling 
these classical requirements. 

Intelligent instruments are computerized devices dis- 
tinguished from non-intelligent ones by the inclusion of a 
microprocessor to fulfill the signal-processing functions. The 
effect of computerization of an instrument is an improvement 
in the quality of the output, measurements, and the general 
simplification of the signal-processing task. Some examples 
of the signal processing that can be performed include cor- 
rection of the instrument output for biases caused by environ- 
mental variations (e.g., temperature, humidity), and ability to 
produce a linear output from a transducer whose characteris- 
tic may be highly nonlinear. 


INTELLIGENT INSTRUMENTS 

Intelligent instruments have functionality of learning and 
adaptation capabilities. Intelligent instruments contain 
embedded processing functionality that provides the compu- 
tational features to perform complex sensing and actuating 
tasks. A typical structure of intelligent instrument is shown 
in Figure 6.1. 

The functions of an intelligent instrument can be sum- 
marized as compensation, information processing, com- 
munications, integration, self-calibration, adaptation, and 
evaluation of the validity of collected data. Information pro- 
cessing encompasses the data-related processing that aims to 
enhance and interpret the collected data and maximize the 
efficiency of the system, through signal conditioning, data 
reduction, event detection, and decision making. 


The communication component of intelligent instrument 
systems incorporates the standardized network protocol, 
which serves to link the distributed instruments in a coher- 
ent manner, enabling efficient communications and fault tol- 
erance. Traditional task-specific instrument systems often 
contain a number of limitations in terms of complexity, cost, 
and flexibility. Intelligent instruments aim to overcome these 
limitations through the utilization of standardized trans- 
ducer interfaces and communication protocols, resulting in 
an autonomous, distributed, and reconfigurable instrument. 

As far as the user is concerned, an intelligent instrument 
behaves as a black box, and no knowledge of its internal mode 
of operation is required in normal measurement situations. 
They offer many advantages over their non-intelligent coun- 
terparts, principally because of the improvement in accuracy 
achieved by processing the output of transducers to correct 
for errors inherent in the measurement process. 

Intelligent instruments usually provide many other functions, 
such as: 

1. Signal damping with selectable time constants 

2. Switchable ranges (using several primary transducers 
within the instrument, which each measure over a dif- 
ferent range) 

3. Switchable output units (e.g., display in Imperial or SI 
units) 

4. Diagnostic facilities 

5. Remote adjustment and control of instrument options 

6. Self-calibrations 

7. Various output options, 4-20 mA, Ethernet, Internet, 
wireless, etc. 

8. Self-learning ability 

In this chapter, rather than going into details of the internal 
structures and principles of operations of intelligent instru- 
ments, some typical examples will be provided. The underly- 
ing technologies are also discussed in various other chapters. 

Examples of Intelligent Instruments 

Example 6.i 

Intelligent flowmeters [1-5]: There a many intelligent 
flowmeters commercially available. They are based on 
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FIG. 6.1 

Intelligent instrument architecture. 


different principles for different applications. Some of the 
intelligent flowmeters are as follows: coriolis mass flow- 
meters, electromagnetic flowmeters, ultrasonic flowme- 
ters, variable area, vortex flowmeters, water flowmeters, 
oil flowmeters, metal rotameters, steam flowmeters, gas 
flowmeters, air flowmeters, mass flowmeters, etc. 

As an example, a typical intelligent vortex flowmeter 
contains four-piece piezoelectric sensors two of which 
are used to detect the flow of fluid and the other two 
for detecting the vibration signal of the pipe. It can pro- 
vide temperature and pressure compensation. The meter 
parameters and meter range can be changed by manual 
buttons. It provides 4-20 m A current signal output/pulse 
signal and communicates with HART communication 
protocol. Profibus, and Foundation Fieldbus. Liquid crys- 
tal displays can exhibit the instantaneous flow and accu- 
mulated flow of measured medium simultaneously. 

Another example is the intelligent electromagnetic 
flowmeter used for high-viscosity uniform medium such 
as detecting paper pulp, mud, cement slurry, and mor- 
tar. It has compensation capability for fluid density, vis- 
cosity, temperature, and pressure change. It has double 
flow direction measurement and double direction quan- 
tum accumulating function. It uses HART protocol for 
communications. 


Example 6.2 

Intelligent temperature transducers [6-8]: A typical 
intelligent temperature transducer is capable of mea- 
suring and controlling temperature. They can use field- 
bus protocols to read measured values, set alarm limits 
and adjust the probes, and read firmware version. For 
this, appropriate ports are used to set alarm limits, time 
delays, e-mail addresses, probe description, refresh of 
www pages, select type of www pages, set storing inter- 
val to history, automatic IP address assignment from a 
server. In case of alarm creation, warning e-mail message 
is sent to addresses defined by the user. 

Another example of an intelligent temperature trans- 
ducer is the Ethernet interface capable temperature 


sensor. A typical device can sense display and commu- 
nicate: temperature, barometric pressure, relative humid- 
ity, dew point temperature, absolute humidity, specific 
humidity, mixing ratio, and specific enthalpy. Its commu- 
nications modes are 

• Modbus protocol enables to read measured values, 
set alarm limits, adjust the probe, and read firm- 
ware version. 

• Telnet Port 9999 enables to set alarm limits (lower 
and upper limits for T, RH, Tdp, hysteresis, and 
time delay), e-mail addresses, simple network 
management protocol (SNMP) addresses, probe 
description, refresh of www select type of www 
pages, set storing intervals to history, and enable 
each communication channel. 

• VPIVIV pages : User selectable design of www pages 
enabling to display curves of measurement history. 
User can design the look of www pages and select 
values to display. 

• SNMP: It is possible to read actual values and alarm 
limits. In case of alarm creation, warning message 
(trap) is sent to addresses defined by the user. 

• E-mail: In case of alarm creation, warning e-mail 
message is sent to addresses defined by the user. 

Example 6.3 

Intelligent pressure transmitters [9,10]: A typical intel- 
ligent pressure transmitter has onboard diagnostics, 
time-tracking functions, install date, calibration date, 
time-in-service, stress monitoring, point value, meter- 
body temperature as well as general reading functions. 
All diagnostics automatically run when the transmitter 
is powered and the information can be fed directly into 
the plant’s digital control system and asset-management 
solutions. The information remains in the transmitter for 
use in troubleshooting, with which it can measure abso- 
lute pressure, differential pressure, gauge pressure, flange 
mount, and temperature. It communicates on Foundation 
Fieldbus and HART 5 and 6 protocols. 
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There are many more examples that will not be 
repeated here. Others have similar functionalities and in 
some cases the intelligent instruments use artificial intel- 
ligence to learn from the past data. 


INTELLIGENT SENSORS 

Intelligent sensors and transducers are devices in a single 
chip equipped with the digital electronics that are capable of 
delivering communications, data processing, and self-health- 
monitoring features with minimal cost and power overhead 
on the overall system. Therefore, integration of these devices 
and their protocols that enables a smooth and seamless net- 
working capability to the process is of interest. 

Intelligent sensors uniformly interface with networks 
whenever there is interoperability, agreed protocols, and data 
models such as the IEEE 1451 standards, which is a suite of 
standards addressing data model and operation level interop- 
erability that would be independent of the underlying net- 
work protocols. 

Intelligent Sensor Characteristics and Networking 

A sensor is considered to be intelligent if: 

• It can provide data, a measure of the quality of the 
data, and a measure of the health of the sensor pos- 
sibly using programmable intelligent algorithms. 

• It embodies specification/identification information as 
in the in embedded form on the physical sensor or vir- 
tually on a remote node. 

• It can communicate through a network using TCP/ 

IP or similar protocols to support configuration and 
operation activities. 

In order for sensors to integrate into networks successfully, 
they must embody networking capabilities that provide infor- 
mation flow and control. Currently, there is no defined com- 
mon digital interface standard between transducers and how 
they should provide information flow. However, there is a 
strong push in the industry to harmonize the standards that 
enable networking and data acquisition of sensors. 

IEEE 1451 Standard 

The IEEE-1451 [11] is a set of standards for Smart Sensor 
Networks to unify the data acquisition control systems across 
various transducers. These standards aim to make it easy 
to create solutions using existing networking technologies, 
standardized connections, and common software architec- 
tures. The standard allows application software, field net- 
work, and transducer decisions to be made independently. It 
offers flexibility to choose the products and vendors that are 
most appropriate for a particular application. 


At the process connection level, the IEEE-1451 provides 
standard ways of creating self-describing measurement and 
control devices. Sensors complying with these standards are 
expected to have onboard information on the serial numbers, 
calibration factors, and accuracy specifications, and so on. 
During the installation, location information can also be 
loaded so that the system can have self-describing system 
properties. 

The IEEE P1451 standards come in seven sections. 

1. 1451.0-2007: IEEE standard for a smart transducer 
interface for sensors and actuators — Common func- 
tions, communication protocols, and transducer elec- 
tronic data sheet (TEDS) formats. 

2. 1451.1-1999: IEEE standard for a smart transducer 
interface for sensors and actuators — Network capable 
application processor (NCAP) information model. 

3. 1451.2-1997: IEEE standard for a smart transducer 
interface for sensors and actuators — Transducer to 
microprocessor communication protocols and TEDS 
formats. 

4. 1451.3-2003: IEEE standard for a smart transducer 
interface for sensors and actuators — Digital commu- 
nication and TEDS formats for distributed multidrop 
systems. 

5. 1451.4-2004: IEEE standard for a smart transducer 
interface for sensors and actuators — Mixed-mode 
communication protocols and TEDS formats. 

6. 1451.5-2007: IEEE standard for a smart transducer 
interface for sensors and actuators — Wireless commu- 
nication protocols and TEDS formats. 

7. 1451.7-2010: IEEE standard for a smart transducer 
interface for sensors and actuators — Transducers to 
radio frequency identification systems communication 
protocols and TEDS formats. 

IEEE 1451.1 is termed NCAP information model. This sec- 
tion is concerned with the software architecture that moves 
the intelligence to device level. The 1451.1 approaches 
enable the benefits of objected-oriented technology. It cre- 
ates flexible, natural software modules that allow engineers 
to think at the level of real-world systems, not at the level 
of programming languages. Object-oriented systems are 
built by assembly and produce systems that are much easier 
to adapt to new demands. The object-oriented technology 
makes open systems possible. This breakthrough could have 
the same liberating effect in software configuration as open 
systems had on hardware. In this way, flexibility can be 
achieved so that that system can be assembled, reassembled, 
or modified quickly. 

IEEE 1451.2 is concerned with the transducers and micro- 
processor communication protocols and TEDS. The IEEE- 
1451.2 standard defines the transducer data and electronic 
interface of digital information direct from sensors, thus 
creating a modular architecture. The modular architecture 
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allows embedding of the module to any field networks auto- 
matically and transparently. 

Transducer Electronic Data Sheet 

The heart of the IEEE 1451 standard is the definition of the 
TEDS, the information structure that contains the critical 
sensor information to enable plug-and-play (PnP) operation. 
The TEDS, which typically resides in an EEPROM embed- 
ded in the sensor, is accessed by the measurement system via 
a simple low-cost serial interface. 

IEEE 1451.4 defines the TEDS structure to be very com- 
pact yet flexible and extensible enough to handle a wide range 
of sensor types and requirements. The TEDS basic informa- 
tion contains the required sensor-identification information, 
including manufacturer, model number, and serial number of 
the sensor. The basic TEDS may be followed by a standard 
TEDS that contains the specific “data sheet” information 
for the sensors — typically, the data needed to properly con- 
figure the electrical interface and convert the measurement 
data into engineering units. Typical parameters include mea- 
surement range, electrical output range, sensitivity, power 
requirements, and calibration data. The standard TEDS sec- 
tion as shown in Figure 6.2 describes what is needed to make 
a measurement using the sensors. 

Before installing intelligent sensors, with virtual TEDS 
technology, we can configure traditional analog sensors 
(electronically using binary files). We can use each electronic 


file to store the identification, configuration, and calibration 
information for an individual sensor. In most cases, these 
files are stored in a database where one can easily download 
and use them to configure a sensor for measurement. 

In an example, the virtual TEDS is downloaded from 
the MOBEE NET® [12] (http://mobee.net/) to the MOBEE® 
through the Zigbee and is stored in its flash memory. 
Whenever a sensor corresponding to the TEDS file is plugged 
into one of the MOBEE® input channels, the MOBEE reports 
its TEDS file to MOBEE NET on behalf of the sensor thus 
achieving PnP. Figure 6.3 shows how TEDS are reported 
from MOBEE to MOBEE NET. 

Network Capable Application Processor 

Defined in IEEE 1451, each node primarily consists of three 
fundamental components: the NCAP, smart transducer 
interface module (ST1M), and the physical transducers. The 
NCAP is responsible for providing intelligence and network 
communication with other nodes in the network. The STIM 
is responsible for controlling the transducers and their com- 
munication with the NCAP. The transducers are connected 
to the STIM. The NCAP and the STIM together form a net- 
worked smart transducer. The sensor nodes thus have the 
ability to take crucial decisions on their own and communi- 
cate more efficiently with other nodes in the network. 

NCAP hosts the processor that makes intelligent con- 
trol decisions and is responsible for communication with the 


TEDS 

structure 


Basic TEDS 


Standard and 
extended TEDS 
(fields will vary according 
to transducer type) 


User area 


Example A. IEPE accelerometer 

Manufacturer ID 

43 

Model ID 

7115 

Version letter 

B 

Serial number 

00731F 

Calibration date 

January 29, 2000 

Sensitivity @ ref. 

1.094E + 03 mV/g 

Reference frequency 

100 D Hz 

Reference temp. 

23°C 

Measurement range 

±50 g 

Electrical output 

±5 V 

Quality factor 

300 E-3 

Temp, coefficient 

-0.48%/°C 

Direction (x,y,z) 

X 

Sensor location 

Strut 3A-p2 

Calibration due date 

April 15, 2002 


Example B. 

Bridge (mV/V) load cell 

Manufacturer ID 

21 

Model ID 

19 

Version letter 

D 

Serial number 

0008451 

Calibration date 

February 10, 2001 

Measurement range 

±100 lbf 

Electrical output 

±3.01 mV/V 

Bridge impedance 

350 Cl 

Excitation, nominal 

10VDC 

Excitation, minimum 

7 VDC 

Excitation, maximum 

18VDC 

Response time 

5 ms 

Sensor location 

R32-1 

Cal. record ID 

543-01 23 


FIG . 6.2 

IEEE 1451.4 provides standard templates for about 25 different types of sensors. 
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TEDS communication between MOBEE and MOBEE NET. 



12 bit 

A/D channels 


other NCAPs in the network. It consists of various blocks: 
functional and transducer blocks, and ports (e.g., application 
processors client port, publisher port, subscriber port). Each 
block is in charge of a unique group of functions and man- 
ages associated ports. NCAP block is mandatory but other 
blocks are optional. All of the objects residing in an NCAP 
process are state based. The blocks in the node would have 
different states and sub-states during the lifecycle of the 
node and only particular set operations can be performed by 
a block in a particular state. IEEE 1451.1 defines classes for 
such blocks and ports. It also lists the operations performed 
in each class. 

Smart Transducer Interface Module 

STIM is responsible for housing the transducers and provid- 
ing the information from the transducers to the NCAP. An 
STIM acts as an interface between an NCAP and a trans- 
ducer. It performs the A/D conversion and houses the con- 
trol unit as well. It usually also contains the TEDS, which 
provides calibration and other important information about 
the transducers and the STIM. Figure 6.4 explains the logical 
structure of these devices. 

Communications of Intelligent Sensors 

IEEE 1451.1 provides the object model of the networked 
transducer nodes and how they communicate among them- 
selves. A simple example of two networked nodes commu- 
nicating between themselves is shown in Figure 6.5. IEEE 
1451 supports two paradigms of communication among the 
nodes, which are 


1. Multicast publish-subscribe model 

2. Point-to-point client-server model 

In publish-subscribe communication model, a node pub- 
lishes a message on a multicast address. This publication 
message is received by the nodes with subscription to the 
publication domain specified in the publication message. By 
definition for implementation, publish-subscribe messages 
use UDP sockets in order to send and receive messages. 
This model is primarily used for node discovery and other 
operations. 

Once the nodes are discovered and two nodes have ade- 
quate information (such as object tag and object dispatch 
address) about each other, the two nodes can start client- 
server communication between each other. Major operations 
performed by the NCAPs are client-server operations. The 
communication infrastructure uses TCP/IP for client-server 
communication. 

For communications, the sender must encode the local 
data types in their messages into the types allowed by the 
signatures of PERFORM, EXECUTE, and PUBLISH opera- 
tions. The sender must marshal the message, that is, send the 
message on the network, in a network-specific on-the-wire 
format analogously, the receiver must be able to demarshal the 
message into types allowed by the signatures of PERFORM, 
EXECUTE, and PUBLISH operations. The receiver should 
be able to decode the received message in types allowed by 
the signatures of PERFORM, EXECUTE, and PUBLISH 
operations to its local data types. An on-the-wire docu- 
ment for 1451.1 has been used as a reference to the physical 
transmission requirements: it is based on XDR format where 
the sender must marshal the bytes on any communication 
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FIG. 6.4 

Logical structure of components of an IEEE 1451 sensor node. (Adapted from IEEE 1451.1 document.) 
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FIG. 6.5 

Two networked nodes under test by the tester node in an IEEE 1451 network. 


transport and media, such that the receiver can demarshal 
the bytes and understand the message without any loss of 
meaning. This mechanism is explained in Figure 6.6. 

INTELLIGENT SENSOR PnP CAPABILITY 

A node is PnP if it becomes operational and networked 
immediately after it is turned on while physically connected 
to a network. PnP functionality includes self-announcement, 
self-configuration to a default setting, and acknowledgement 
to clients/servers of its availability to report sensor readings 
or to perform actuator functions. PnP capability is not com- 
plete unless an application layer communication language is 


standardized (e.g., IEEE 1451), which is independent of the 
network and data link layer communication protocols (e.g., 
TCP/IP with ZigBee, TCP/IP with 802.11, etc.). PnP capabil- 
ity of intelligent sensors have found numerous applications 
[13,14], 

A network becomes dynamic when all the elements in the 
network have PnP capability. A node is PnP when it becomes 
operational and networked immediately after turned on and 
is physically connected to a network. Thus, PnP plays a very 
important role in managing a dynamic network. In order to 
be PnP capable, a node has to 

• Announce its presence to other nodes in the network 

• Configure itself to the default settings during a startup 
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FIG. 6.6 

Example of network communication of two nodes. 

• Acknowledge to clients/servers in the network, of its 
availability to report sensor readings or to perform 
actuator functions 

In sensor networks achievement of PnP provides the follow- 
ing advantages: 

• Reduced configuration time by eliminating manual 
data entry 

• Better sensor tracking by storing data sheets 
electronically 

• Improved accuracy by providing detailed calibration 
information 

• Simplified asset management by eliminating paper 
data sheets 

• Reliable sensor location by identifying individual sen- 
sors electronically 

The IEEE 1451.4 standard reduces the time and chal- 
lenges associated with sensor configuration. The standard 
establishes a universally accepted method of giving sensors 
PnP capability, similar to the PnP capability of a USB mouse 
and personal computers. IEEE 1451.4 defines a mechanism 
for adding self-describing behavior to sensors with an analog 
signal interface. 


MANAGEMENT OF INTELLIGENT SENSOR NETWORKS 

Network management is the process of monitoring, control- 
ling, and managing the behavior of a network. Sensor net- 
works pose unique challenges for network management that 
make the traditional techniques impractical. Maintaining 
good health of a sensor network is important in order to get 
reliable sensor data. Mature internet technologies such as 
the simple network management protocol (SNMP) [15,16] 
can be utilized to identify sensors as mere network elements 
to achieve better data-transfer architectures. 


A network management system designed for a sensor net- 
work should provide a set of management functions that inte- 
grate configuration, operation, administration, security, and 
maintenance of all elements and services of a network. The 
network manager should be able to 

• Discover the network topology using the discovery 

messages obtained from all the managed nodes 

• Request information from the managed nodes 

• Track various asynchronous events and alerts initiated 

by the managed nodes 

For such a management, all the manager stations and the 
managed nodes in the network should be made interoperable 
by using a standard application layer protocol as explained 
above. Various existing application layer protocol can be 
used, one such protocol is the SNMP. 

Use of SNMP Protocol for Intelligent Sensors in Networks 

SNMP is a network management protocol that has been used 
to manage the networks for a long time since its inception in 
the early 1990s. In an SNMP system, one or more admin- 
istrative computers are called “managers” with the task of 
monitoring or managing a group of nodes or devices, where 
each managed node executes a software component called an 
“agent” and reports information via SNMP to the manager 
systems, as shown in Figure 6.7. 

Since its creation, SNMP has been the solution for man- 
aging network elements in ever-growing applications and 
has achieved widespread acceptance because of its simplic- 
ity. It is based on the manager/agent model consisting of an 
SNMP manager, an SNMP agent, and database of manage- 
ment information, managed SNMP devices, and the net- 
work protocol. The SNMP manager provides the interface 
between the human network manager and the management 
system. The agent provides the interface between the man- 
ager and the physical devices being managed by communi- 
cating between the SNMP manager and the SNMP agent as 
illustrated in Figure 6.8. 

The GET and GET-NEXT messages allow the manager 
to request information for a specific variable. The agent upon 
receiving a GET or a GET-NEXT message, will issue a GET- 
RESPONSE message to the SNMP manager with either the 
information requested or an error indication as to why the 
request cannot be processed. 

A SET message allows the SNMP manager to request a 
change be made to the value of a specific variable, to which 
the SNMP agent will then respond with a GET-RESPONSE 
message indicating the change has been made or an error 
indication as to why the change cannot be made. 

The SNMP TRAP message allows the agent to spontane- 
ously inform the SNMP manager of an important event or to 
report an alarm. Most of the messages (GET < GET-NEXT 
and SET) are only issued by the SNMP manager. 
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FIG. 6.7 

SNMP Architecture. 
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FIG. 6.8 

SNMP messages between the manager and the agents. 


SNMP provides the following features that are relevant to an 
intelligent sensor network: 

1. SNMP network topology discovery. The protocol pro- 
vides a way to discover various SNMP-managed nodes 
in the network using SNMP ping. Thus, the manager 
can request information using SNMP protocol from 
any of the discovered nodes. 

2. SNMP information exchange : An agent maintains 
information about the predefined management 


variables and reports to the manager when requested. 
The managing system can retrieve the information 
through the “GET,” “GETNEXT,” and “GETBULK” 
protocol operations. Management systems can also 
change the configuration or control variables through 
the “SET” protocol operation to actively manage a 
system. 

3. SNMP alert/event monitoring : The agent also has the 
capability of reporting asysnchronous messages to 
manager systems using “TRAP.” These messages are 
used to notify the manager about the alerts or special 
events that are to be monitored. 

SNMP by itself does not define which information or vari- 
ables a managed system should offer. Instead, it uses an 
extensible design, where the available information is defined 
by management information bases [17] (MIBs). MIB stems 
from the OSI/ISO network management model and is a 
type of database that follows the structure of management 
information used to manage the devices in a communication 
network [18,19], It comprises a collection of objects in a data- 
base that is used to manage entities. 

Since the network consists of components manufactured 
by multiple vendors, commonality in the definition and rela- 
tionship of component attributes is needed. MIBs describe 
the structure of the management data of a device subsystem. 
They use a hierarchical namespace containing object identi- 
fiers (OID). Each OID is unique and identifies a variable that 
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can be read or set via SNMP. The MIB is used by both agent 
and management processes to store exchange management 
information. A manager MIB consists of information on all 
the network components that it manages, whereas an agent 
MIB needs to know only its local information. 

1. Monitoring devices to display and record the values of 
process variables 

2. Control devices to act on processes in order to control 
their variables 

The data transfer interfaces between units are described in 
this section. The main interfaces under consideration are 

1. Packet and on-the-wire format of SNMP messages 
between an intelligent sensor node and the SNMP 
manager host PC 

2. Packet and on-the-wire formats of messages between 
transducer node and the intelligent sensor node 

All SNMP devices must understand an SNMP message: dif- 
ferent software languages may have slightly different sets 
of data types (integers, strings, bytes, characters, etc). For 
example, an SNMP manager sending a message full of Java 
data types may not be understood by an SNMP agent writ- 
ten in C. To solve this problem, SNMP uses abstract syntax 
notation one (ASN.l) to define the data types used to build 
an SNMP message. Since ASN.l is independent of any par- 
ticular programming language, the SNMP agents and man- 
agers may be written in any language. However, even when 
using valid ASN.l data types another problem still exists. 
When sending a particular data type over the wire, how 
should it be encoded? Should the strings be null-terminated 
or not? Should Boolean values be 8 bits as in C++ or 16 bits 
as in Visual Basic 6? ASN.l includes basic encoding rules 
(BER) to address this problem. Regardless of programming 
language, all data types are encoded the same way before 
they are placed on the wire by following the BERs. To send 
a properly formatted message, the programmer must under- 
stand ASN.l and the BERs. 

ASN.l: Constructing a message requires some knowledge of 
the data types specified by ASN.l, which fall into two cat- 
egories: primitive and complex. ASN.l primitive data types 
include the following: 

1. Integer 

2. Octet (byte, character) string 

3. Null 

4. Boolean 

5. OID 

ASN.l offers several complex data types necessary for build- 
ing SNMP messages. One complex data type is the sequence. 
A sequence is simply a list of data fields. Each field in a 
sequence can have a different data type. ASN.l also defines 


the SNMP protocol data unit (PDU) data types, which are 
complex data types specific to SNMP. The PDU field contains 
the body of an SNMP message. Two PDU data types available 
are GetRequest and SetRequest, which hold all the necessary 
data to get and set parameters, respectively. Ultimately, the 
SNMP message is a structure built entirely from fields of 
ASN.l data types. However, specifying the correct data type 
is not enough. If the SNMP message is a sequence of fields 
with varying data types, how can a recipient know where one 
field ends and another begins, or the data type of each field? 
Avoid these problems by conforming to the BERs. 

Basic Encoding Rules 

Follow the BERs when laying out the bytes of an SNMP 
message. The most fundamental rule states that each held is 
encoded in three parts: 

1. Type: It specifies the data type of the held using a sin- 
gle byte identiher. For a brief table of some data types 
and their identihers, see Table 6.1. 

2. Length: It specihes the length in bytes of the following 
data section. 

3. Data: It is the actual value communicated (the num- 
ber, string, OID, etc.). 

The SNMP message format: The SNMP message format 
specihes which helds to include in the message and in what 
order. Ultimately, the message is made of several layers of 
nested helds. At the outermost layer, the SNMP message is 
a single held, of the sequence type. The entire message is a 
sequence of three smaller helds: the SNMP version (integer), 
the SNMP. 

The SNMP version and the community string are primi- 
tive data types. Therefore, there are no more layers to repre- 
sent these helds. However, the PDU is a complex data type. 
The PDU is composed of a request ID (integer), error (inte- 
ger), error index (integer), and a varbind list. A varbind or 
variable binding is a sequence of two specihc helds. The hrst 
held is an OID, which addresses a specihc parameter. The 
second held contains the value of the specihed parameter. 
In a SetRequest, value must be the same data type specihed 
in the MIB for the parameter being set. In a GetRequest, 
value is a null with length 0x00. These null data are a place- 
holder for the value data that the SNMP agent returns using 


TABLE 6.1 

Data Types and Their Identifiers 

Primitive 
Date Types 

Identifier 

Complex Data 
Types 

Identifier 

Integer 

0x02 

Sequence 

0x30 

Octet string 

0x04 

GetRequest PDU 

OxAO 

Null 

0x05 

GetRequest PDU 

0xA2 

OID 

0x06 

SetRequest PDU 

0xA3 
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(octet string) 





Varbind list (sequence) 




Varbind (sequence) 




Object identifier 
(OID) 




Value (integer, octet 1 


string, etc.) 


FIG. 6.9 

SNMP PDU lower layers. 


the GetResponse PDU. Furthermore, as the name suggests, a 
varbind list is a sequence of varbinds. Finally, when a mes- 
sage is setting or getting a single parameter, the varbind list 
holds only one varbind. For an explanation of each field in the 
SNMP message see Figure 6.9. 

1. Packet and on-the-wire format of SNMP messages 
between an intelligent sensor node and the SNMP 
manager host PC. 

These messages follow the format outlined pre- 
viously. The packet formats are SNMP messages: 
GetRequest. And, on-the-wire format of the pack- 
ets follow the ASN.l standard with Basic Encoding 
Rules (BER) that dictate type-length-value fields to 
be present. 

2. Packet and on-the-wire formats of messages between 
transducer node and the intelligent sensor node. 

STANDARDIZED REFERENCE TO INTEGRATED 
INTELLIGENT SENSORS 

There are numerous vendors in the industry manufacturing 
various types of network components. Therefore, there is a 
requirement for some commonality in the definition and rela- 
tionship of network components attributes. M1B is a type of 
database that can be used to manage the sensors and other ele- 
ments in the network. If we have a standard MIB defined for 
all components that make up a sensor network, then it will be 
simple and easy to identify them and will not be constrained by 
the manufacturing vendor of the product. This helps in making 
the process of managing them in a straightforward manner. 

There is a need for a standardized way of obtaining infor- 
mation related to the physical sensors that are commonly 
found in networking equipment. Information as the current 
value of the sensor, the current operational status, and other 
information associated with the sensor should be represented 
in a consistent manner for any type of sensor. 

The idea is to extend the concept of IEEE 1451.4 TEDS 
to the entity-sensor MIB. The MIB structure allows the user 
to define an SNMP table as an ordered collection of objects 
consisting of zero or more rows. Each row may contain one 
or more objects. Each object in a table is identified using the 
table index. A table can have single index or multiple indices. 


To identify a specific columnar variable, the index of the row 
has to be appended to its OID. SMIv2 extends the concept 
of table for an aggregate object from a single table to mul- 
tiple tables. This allows for the expansion of managed objects 
when the number of columnar objects needs to be increased, 
or when the objects are best organized by grouping them 
hierarchically. 
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